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ABSTRACT 

The development of Nascom systems for 
ground communications began in 1958 
with Project Vanguard. The low-speed 
systems (rates less than 9.6 Kbs) were 
developed following existing standards; 
but, there were no comparable standards 
for high-speed systems. As a result, 
these systems were developed using 
custom protocols and custom hardware. 

Technology has made enormous strides 
since the ground support systems were 
implemented. Standards for computer 
equipment, software, and high-speed 
communications exist and the 
performance of current workstations 
exceeds that of the mainframes used in 
the development of the ground systems. 

Nascom is in the process of upgrading its 
ground support systems and providing 
additional services. The Message 
Switching System (MSS), 
Communications Address Processor 
(CAP), and Multiplexer/Demultiplexer 
(MDM) Automated Control System 
(MACS) are all examples of Nascom 
systems developed using standards such 
as, X-windows, Motif, and Simple 
Network Management Protocol (SNMP). 
Also, the Earth Observing System 
(EOS) Communications (Ecom) project 
is stressing standards as an integral part 


of its network. The move towards 
standards has produced a reduction in 
development, maintenance, and 
interoperability costs, while providing 
operational quality improvement. 

The Facility and Resource Manager 
(FARM) project has been established to 
integrate the Nascom networks and 
systems into a common network 
management architecture. The 
maximization of standards and 
implementation of computer automation 
in the architecture will lead to continued 
cost reductions and increased operational 
efficiency. The first step has been to 
derive overall Nascom requirements and 
identify the functionality common to all 
the current management systems. The 
identification of these common functions 
will enable the reuse of processes in the 
management architecture and promote 
increased use of automation throughout 
the Nascom network. 

The MSS, CAP, MACS, and Ecom 
projects have indicated the potential value 
of commercial-off-the-shelf (COTS) and 
standards through reduced cost and high 
quality. The FARM will allow the 
application of the lessons learned from 
these projects to all future Nascom 
systems. 
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INTRODUCTION 

The development of NASA 
Communication (Nascom) systems for 
ground communications began in 1958 
with Project Vanguard. The low-speed 
systems (less than 9600 bps) were 
developed following existing standards. 
However, the existing communication 
standards could not be used to meet the 
higher data rates and transmission 
reliability requirements demanded by 
next generation of NASA projects. As a 
result, custom protocols and associated 
hardware had to be developed to meet the 
needs of the growing space agency. 

The Nascom protocol that was developed 
in 1968 consisted of a 1200-bit block 
with header information, data field, and 
polynomial error control field at the end. 
Over time, user communication 
requirements increased and the Nascom 
block size was increased to 4800 bits. 
The basic structure remained the same, 
but provided an expanded user data field. 

In the 1970's, development began on a 
system of geosynchronous satellites to 
relay data around the world instead of 
many earth stations. As the Tracking and 
Data Relay Satellite System (TDRSS) 
grew, it became evident the manual 
network control and monitoring would be 
impossible. Nascom began to automate 
its portion of the network. 

Once again, network management 
standards did not exist to meet NASA's 
requirements. Nascom began custom 
development for automated network 
management, using the existing Nascom 
protocol with 1200-bit blocks as the 
management protocol. 

With today's reality of budget reductions 
and the high cost of custom development, 
the use of standards has become as 
important as high-speed and data 


integrity. Fortunately, communication 
standards for both transmission and 
management had been developing over 
the last few years to keep up with user 
demands. 

Nascom began its move towards 
standards with development of an X.25 
network for the Pacor/Gamma Ray 
Observatory (GRO) project and the 
Mission Operations and Data Systems 
Directorate (MO&DSD) Operational/ 
Development Network (MODNET)/ 
Nascom Operational Local Area Network 
(NOLAN) for high-speed local data 
distribution. Now, Nascom is 
developing a high-speed Asynchronous 
Transfer Mode (ATM) network for the 
EOS project and re-engineering its 
automated network management 
architecture to integrate these standards- 
based networks and the existing 
customized network into a centralized 
operations area. 

EXISTING ARCHITECTURE 

Nascom currently has three distinct 
networks with separate management 
systems: the Data Distribution and 
Command System (DDCS), MODNET, 
and the 4800-bit block network. 

The DDCS X.25 network has two nodes 
located at GSFC, a node at Marshall 
Space Flight Center (MSFC) and a node 
at the University of California at Berkeley 
(UCB) (figure 1), distributing X.25 
packets at data rates up to 224 Kbps. 
Each node has a redundant backup for 
automatic fail over. It is composed of 
COTS hardware and software with 
integrated network management 
software. The controlling node is located 
in the Nascom computer facility at 
GSFC. 
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Figure 1. The DDCS 


The second network is the Mission 
Operations and Data Systems Directorate 
(MO&DSD) Operational/ Development 
Network (MODNET). MODNET was 
formed in May 1986 through the 
integration of three division-level 
networks: the MOD&DSD Network 
(MNET), Mission Operations Division 
(MOD) Local Area Network 


(MODLAN), and the Information 
Processing Division LAN (InfoLAN). 
This network provides high-speed, 50 
Mbps, interconnectivity between 
operational LANs and computer systems 
at GSFC (figure 2). 

The LAN technology used by 
MODNET is HYPERchannel. 



Figure 2. MODNET 
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HYPERchannel, a registered trademark, 
is a generic name for the various network 
components and protocols developed by 
Network Systems Corporation (NSC) to 
provide networking capabilities between 


entities within Nascom to handle the data 
requirements each with their own control 
capabilities. The MSS is the original 
Nascom block star network hub (figure 
3). The MSS provides packet switching 



Figure 3. The MSS 


networked computers. The fastest 
alternative protocol at the time MODNET 
was formed was the 10 Mbps Ethernet. 

The NOLAN will expand upon 
MODNET's capabilities using a Fiber 
Distributed Data Interface (FDDI) 
backbone with a larger distribution area. 
MODNET/NOLAN will be managed by 
Nascom operations using Hewlett- 
Packard's HP Openview network 
management system with ISICAD for 
automated trouble ticketing. 

The final network is the 4800-bit block 
network that distributes data throughout 
the world with data rates ranging from 50 
baud to 2 Mbps. There are two network 


capabilities for hundreds of 4800-bit 
block users with data requirements 
ranging from 9600 bps to 1.544 Mbps. 
The management control consists of 
custom developed software operating on 
a Sun workstation. 

The TDRSS network portion of Nascom 
consists of custom built 
Multiplexer/Demultiplexers (MDMs) and 
controllers located at the Johnson Space 
Center (JSC), NASA Ground Terminal 
(NOT), MSFC, and GSFC, a custom 
Digital Matrix Switch (DMS) and 
controller at GSFC, and custom Data 
Link Monitoring Systems (DLMS) 
located at GSFC, JSC, and NGT. This 
network equipment is being constantly 
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reconfigured according to the network 
schedule supplied by the Network 
Control Center at GSFC. In order to 
meet the reconfiguration requirements of 
the network, the Control and Status 
System (CSS) was a custom 
development to provide automated 
network management (figure 4). The 
CSS uses the Nascom 1200-bit block to 
send commands and receive status from 
the network equipment. 


and engineer an efficient network 
management architecture using new 
technology and standards. Computer 
workstations today can process the same 
data that required mainframes ten years 
ago. Standard protocols can send data at 
higher rates and provide interconnectivity 
between different hardware platforms. 
COTS software packages can be found to 
meet almost every need. Custom 
systems are not an effective application of 
limited resources any more. 



Figure 4. The CSS 


MORE WITH LESS 

Do more with less is the motto of the 
world today. Every year, the demand 
increases and the budget decreases. In 
order to maintain communication 
services for the Agency, Nascom has 
begun a project to re-engineer its network 
management architecture. 

The Facility and Resource Manager 
(FARM) is an attempt to step back, 
analyze Nascom's management 
requirements, with an eye to the future, 


The basic goal of the FARM is to meet 
today's motto, more with less. More 
network operational demands with less 
budget cause additional capabilities and 
requirements to be engineered into the 
systems with less engineering budget. 
Standards, COTS, reuse, and new 
technology are the FARM'S tools. 

Operational Costs 

The biggest cost to Nascom operations is 
the large number of personnel required to 
run the networks. The 4800-bit block 
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network is very manually intensive and 
operates in a reactive mode for 
troubleshooting. MODNET, NOLAN, 
and the X.25 networks are a little more 
automated, less personnel dependent; but 
being separate networks, they still require 
additional operations personnel. In the 
near future, Nascom will implement and 
operate the Federal Telecommunications 
System (FTS)-2000 network and the 
EOS Communications (Ecom) ATM 
network. Although these are both highly 
automated networks, they also have their 
own network management systems that 
have to be operated, requiring additional 
personnel. 


from text menus to windowed graphical 
interfaces. Comprehensive operator 
training for each system has to be 
developed, which is time consuming and 
expensive. 

THE FARM ARCHITECTURE 

The FARM is developing the functional 
requirements of all the management 
systems and designing a workstation- 
based distributed network management 
architecture using SNMP between the 
systems. By down-sizing from 
mainframes, using COTS products, and 
Object Oriented (OO) development 
methodologies for software reuse, the 



Figure 5. The FARM 


Engineering Costs 

Nascom engineering costs largely come 
from developing and maintaining 
specialized hardware and software. Until 
recently, to perform real-time processing 
of large amounts of data required the use 
of mainframes in conjunction with mini- 
computers and large amounts of 
assembly code. Add to that a unique 
protocol, requiring specialized hardware, 
and you have a recipe for a marching 
army of software and hardware engineers 
to keep Nascom operational. 

Another cost is training personnel on 
every new system or network. Every 
one of the management systems operated 
by Nascom has a different user interface, 


FARM will reduce engineering costs and 
development time. By consolidating 
multiple network management systems 
into a consolidated environment, the 
FARM will provide a consistent operator 
interface into the different networks, 
reducing training time and the need for 
separate operators for each system 
(figure 5). 

The FARM has five functions: operator 
interface, data management, resource 
scheduling, system automation, and a 
non-SNMP gateway (figure 6). The 
operator interface will be designed using 
X-window and Motif standards to 
provide a comprehensive graphical user 
interface. COTS development tools, such 
as TAE+, will be used to provide rapid 
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screen prototyping. This will allow the 
FARM the capability to provide the most 
efficient user interface in the shortest 
amount of time. 

The data management function will 
provide storage and retrieval of network 
configuration, management, and 


project is evaluating several vendor 
packages for most comprehensive 
adherence to requirements. 

System automation will be provided by 
using expert systems. Several of the 
COTS management systems also provide 
expert system development tools. The 


NCC 


Facility 

Sensor 

MDM 



Figure 6. The FARM Functions 


statistical information for the FARM. 
This functional will be performed using a 
Structured Query Language (SQL)-based 
database management system, such as 
Oracle or Sybase. 

The resource scheduling function 
provides the FARM with the ability to 
configure TDRSS network equipment 
according to the network event schedule 
supplied by the Network Control Center. 
A large portion of this function can be 
performed by COTS network 
management software. The FARM 


expert systems will analyze alarms and 
passive circuit monitoring equipment to 
perform pro-active troubleshooting for 
the network. 

The Nascom networks have equipment 
and interfaces with specialized protocols. 
These non-SNMP interfaces will require 
gateways to convert between protocols. 
Again, several of the COTS management 
systems provide the capability to define 
unique interfaces. 
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DEVELOPMENT 

METHODOLOGY 

Development costs will also be reduced 
by applying some of the ideas from 
Object-Oriented (OO) methodologies to 
enhance reuse of already developed 
components and COTS products. 

The FARM will not use an OO 
implementation language, as the project’s 
short schedule, the long learning curve 
for OO methodologies, and the 
questionable success of OO projects are 
incompatible. Instead, the ideas within 
OO development that have been designed 
to enhance reuse are being employed. 

The first of these OO development ideas 
is to perform a problem domain analysis. 
A domain is a problem area defined by 
the user interface, external interfaces and 
interaction of a proposed system. Its 
extent depends, in large, on the definition 
of what a user is. In the case of the 
FARM, users are operations personnel 
and developers. However, the developer 
is a user only to the extent necessary to 
safeguard reuse. 

The problem domain analysis concludes 
with the specification of a development 
framework. The framework consists of 
the components identified in the problem 
domain analysis that appear to be 
candidates for reuse or COTS products in 
the system. 

TESTING METHODOLOGY 

COTS and reusable components are 
integrated into system development 
following System Engineering and 
Analysis Support (SEAS) System 
Development Methodology (SSDM). 
There are different levels of development 
testing required for COTS and reusable 
components depending on their level of 
reusability. The basic idea is that the 


supplied component is assumed to be 
fully tested and working. The task of 
development testing is to ensure it works 
within the system, that the interfaces are 
functioning as stated. System testing 
remains the same: the system is still 
tested to ensure requirements are met. 

The level of testing, and when testing 
begins, depends on the component’s 
position in the hierarchy of system 
components. When an entire function is 
reusable or COTS, the lowest level of 
testing required is module testing to 
ensure that the interface matches 
expectations. If the supplied function is 
more-or-less a client/server function, then 
integration testing is required to ensure 
that the client/server interface is correct. 

Using the definition of a process as the 
smallest stand-alone system entity; 
testing should start at the level of testing 
in the following table: 


Table 1. Testing Requirements 


Level of 
Reuse/COTS 

Testing Required 

One or more 
processes 

Integration testing 

Complete 

function 

Integration testing or 
Module testing 

One or more 
units 

Module testing 

Modified unit 

Unit testing 


IMPLEMENTATION PLAN 

The integration of management systems 
will be done in a phased approach, 
attacking the manually intensive legacy 
systems first, then moving to the more 
automated standards-based networks in 
later phases. This will allow Nascom to 
replace the expensive custom control 
systems, reducing the software 
maintenance costs. 
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The CSS and its associated control 
systems in the TDRSS network will be 
re-engineered to provide the framework 
for the consolidated network operations 
center. These systems are the most 
manually intensive, least automated 
systems. By consolidating these systems 
and implementing expert systems 
technology, operational costs will be 
greatly reduced. 

Future phases of the FARM will integrate 
the remaining COTS management 
systems through SNMP interfaces and 
increasing operational automation. 

A FARM lab is being developed which 
will be used to evaluate and test different 
hardware platforms and software 
packages, perform network performance 
analysis, and prototype new technologies 
and configurations for use in the FARM. 
By performing rapid prototyping and 
evaluation on every aspect of the FARM 
development, road blocks and design 
flaws will be identified early in the project 
life cycle. 

CONCLUSION 

The Nascom networks have evolved over 
the last thirty years into what they are 
today. Each system and network were 
developed to meet a specific set of 
requirements to support NASA's 
communications needs. Today, 
technology and standards have matured 
to the point that it makes engineering 
sense, as well as budgetary sense to start 
over from the beginning and re-engineer 
Nascom's network management 
architecture. 


1141 



